The present invention relates to downlink data transfer in a UMTS terrestrial radio access network (UTRAN). A UTRAN wireless communication network 10 is depicted in FIG. 1. The UTRAN network comprises a Core Network (CN) 12, a plurality of Radio Network Controllers (RNC) 14, and plurality of NodeBs 20, also known in the art as Base Stations, each providing communication services to one or more User Equipment (UE) 24, also known as mobile stations, across an air interface within a cell or sector 26.
The CN 12 may be communicatively coupled to other networks such as the Public Switched Telephone Network (PSTN), the Internet, a GSM network, or the like. Each RNC includes, among other functional modules, a Radio Link Protocol (RLC) 16 and a dedicated Medium Access Control (MAC-d) 18. The RLC 16 transfers data to the MAC-d 18 on a plurality of logical channels 17. With the advent of High-Speed Downlink Packet Access (HSDPA), the NodeB 20 communicates with each UE 24 on dedicated channels and additionally broadcasts data packets throughout the cell 26 on a High Speed Downlink Shared Channel (HS-DSCH).
HSDPA utilizes channel-dependent scheduling, whereby data directed to each UE 24 is scheduled for transmission on the shared channel when the instantaneous channel quality to that UE 24 is high. Similarly, fast rate control and higher order modulation are used for link adaptation, wherein the data rate of each transport block and the modulation scheme are varied in response to channel conditions to the target UE 24 (and the capability of the UE 24). In addition, HSDPA employs a hybrid-ARQ (HARQ) acknowledgement scheme, wherein soft values of unsuccessfully decoded transport blocks are retained and combined with the soft decoding results of each retransmission. This allows for incremental redundancy, reducing the need for further retransmissions. Because the scheduling, rate adaptation, and HARQ functions must be close to the radio interface on the network side, a high speed Medium Access Control (MAC-hs) function 22 is added to the NodeB 20. A MAC-ehs function (not shown) is additionally provided in UE 24 capable of receiving HSDPA traffic.
The 3rd Generation Partnership Project (3GPP) standard defines MAC-d multiplexing, whereby data from a plurality of logical channels may be multiplexed into one MAC-d flow and encapsulated into MAC-d Protocol Data Units (PDUs). This functionality was developed for Release-99 channels, when priority-based scheduling on transport channels was performed entirely in the RNC 14. To distinguish the logical channel, a 4-bit C/T field is added to a multiplexed MAC-d PDU header (non-multiplexed PDUs need not include the C/T field). The logical channels that are MAC-d multiplexed in the RNC 14 are handled as one MAC-d flow through the Transport Network (i.e., between the RNC 14 and the NodeB 20 over the Iub) and, typically, as one priority flow (or queue) over the air interface. This enables data from a number of Radio Bearers (RB) to be transmitted over a single MAC-d flow, reducing the number of Priority Queues (PQs) in the NodeB. Additionally, with fewer MAC-d flows, the number of transport network links is reduced, which may alleviate address space constraints in UE 24 having limited MAC-d flow capacity.
The multiplexing MAC-d functionality is depicted in FIG. 2. A C/T multiplexer 28 multiplexes data from a plurality of logical channels into one MAC-d flow. The C/T MUX Priority Controller 30 only performs priority setting for the downlink if the C/T mux 28 is removed. FIG. 3 depicts the mapping of MAC-d flows into PQs 32 in the MAC-hs 22 in the NodeB 20. The reordering of PDUs in MAC-hs functionality in the UE 24 is depicted in FIG. 4. The reordering is performed on a per-PQ 32 basis; thus the UE 24 must configure as many reordering queues 34 as there are PQs 32.
The above-described system is deficient in several respects. First, the MAC-d PDU is ideally octet-aligned. The MAC-d receives RLC PDUs, which are octet-aligned in both acknowledged mode (AM) and unacknowledged mode (UM). However, by adding a 4-bit C/T field to the header, the MAC-d PDUs are no longer octet-aligned. This is problematic for the design of new headers, such as for encapsulating the data in lower network protocol layers, as many headers include a length indicator (LI) indicating the size of the MAC-d PDU. Non-octet alignment means more bits are required for the LI. Non-octet-aligned protocol structures also require more processing.
Second, the multiplexing with the C/T field generates unnecessary overhead, reducing the effective bandwidth of the air interface. A multiplexed MAC-d PDU header includes a 4-bit C/T field indicating a logical channel associated with the data. The MAC-hs later adds an additional 3-bit field indicating the PQ from which a MAC-d PDU is taken for transmission over the air interface. Accordingly, a total of seven bits are used to indicate the logical channel origin of the MAC-d PDU, when only four or five bits are actually needed.
Removal of the C/T field from the header of a multiplexed MAC-d PDU would alleviate both deficiencies. A straightforward solution for then identifying the logical channel origin of the data would be to assign a one-to-one mapping between logical channels and PQs 32, and perform reordering in the UE 24 on a per-logical channel basis. However, this would result in a proliferation of separated MAC-d flows and PQs 32, increasing processing demands in both the NodeB 20 and UE 24. It would also radically alter the multiplexing structure of the MAC by removing the concepts of MAC-d flows and PQs 32. Accordingly, a need exists in the art to maintain the multiplexing structure defined in the MAC but remove or mitigate the deleterious effects of the C/T field, while maintaining the ability to implement a low number of MAC-d flows and PQs 32.